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A method is provided for sending data from a data 
source executing a network protocol such as the 
TCP/IP protocol stack, which includes a process for 
generating headers for packets according to the 
network protocol. The method includes sending 
such data on a network through a smart network 
interface. The network protocol defines a datagram 
in the data source, including generating a header 
template and supplying a data payload. The 
datagram is supplied to the network interface. At the 
network interface, a plurality of packets of data are 
generated from the datagram. The plurality of 
packets include respective headers, such as TCP/IP 
headers, based on the header template, and include 
respective segments of the data payload. The 
network interface supports packets having a pre- 
specified length, and the data payload is greater than 
the pre-specified length, such as two to forty times 
larger or more. Thus, the higher layer processing 
specifies a very large datagram, which is 
automatically segmented at the network interface 
layer, instead of at the TCP layer. 
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BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to network protocols for data networks; and more particularly to a process 
offloading higher protocol layer processing such as TCP/IP processing for sending data files onto a sma 
network interface adapter. 

2. Description of Related Art 

Data networks are controlled by network protocols which according to the commonly used ISO model a 
classified into layers. The ISO layers include a physical layer, a data link layer of which the medium acc 
control MAC layer is a subset, a network layer and so on. 

The physical and MAC layers are typically implemented on network adapter cards with efficient integra 
circuits. Higher layers are handled by software drivers for the adapter cards and by a protocol stack 
executed in the host processor. The drivers and protocol stack require relatively intense processing by tt 
host, particularly in serving applications that require substantial network traffic. 

According to typical protocols, the host processor composes the packets, generates headers and checksu 
and transfers the composed packets down the stack to the driver. The driver sends the packet to the 
network adapter card. As the data is transferred down the stack to the card, significant host processing a 
each layer is required. 

One common protocol stack includes the transmission control protocol TCP running over the Internet 
Protocol IP, commonly referred to as TCP/IP. TCP is a connection oriented, end-to-end reliable protoco 
designed to fit into a layered hierarchy of protocols which support multi-network applications. Processe; 
running in the host system transmit data by calling on TCP and passing buffers of data as arguments. Th 
TCP packages the data from these buffers into appropriately sized segments, and calls on the IP layer to 
transmit each segment to the destination. On the receive side, the TCP stack/layer places the data from c 
or more segment into the receiving user's buffer, and notifies the receiving user. 

The IP module is associated with the TCP and provides an interface to the local network. This IP modul 
packages the TCP segments inside Internet packets and routes these packets to a destination at the IP la) 
or to an intermediate gateway. The IP module may also break the TCP segments into smaller BP fragmei 
to address lower layer packet size issues. To transmit the packet through the local network, it is embedd 
in a local network packet at lower layers of the process. The drivers at the lower layers may perform 
further packaging, fragmentation or other operations to achieve the delivery of the local packet to the 
destination. 

Transmission according to the TCP/IP model is made reliable via the use of sequence numbers and 
acknowledgments. Conceptually, each octet of data is assigned a sequence number. The sequence numb 
of the first octet of data in a segment is transmitted with that segment, and is called the segment sequenc 
number. Segments also carry an acknowledgment number which is the sequence number of the next 
expected data octet of transmissions in the reverse direction. When the TCP module transmits a segmen 
containing data, it puts a copy on the transmission queue and starts a timer. When acknowledgment for 1 
data is received, the segment is deleted from the queue. If the acknowledgment is not received before th 
timer runs out, the segment is retransmitted. 
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To govern the flow of data between TCP modules, a flow control mechanism is employed. The receivin 
TCP module reports a window to the sending TCP. This window specifies the number of octets, starting 
with the acknowledgment number, that the receiving TCP is currently prepared to receive. The number • 
bytes specified as the window, is the maximum number of bytes which a sender is permitted to transmit 
until the receiver opens some additional window. Thus, the sender controls the amount of data sent onto 
the network so that it does not exceed the size of the advertised window of the destination. 

According to the typical prior art system, the size of the segment sent by the TCP protocol down to the 1 
layer must match one-to-one with the packets transmitted by the IP layer to the network (ignoring IP 
fragmentation). The driver passes packets from the IP layer to the MAC in the network interface card. F 
example, in the network driver interface specification NDIS driver model for Windows based platforms : 
packets are passed to the MAC driver as NDIS- PACKET structures. These structures are basically a li: 
of buffers that put together make up the packet. Also, some out-of-band OOB data is allowed per packel 
according to the NDIS model (for example, an indication of priority). These packet structures are 
constrained to the maximum packet size for the media, for example 1514 bytes for Ethernet. This packe 
size structure propagates up the TCP/IP protocol stack. This requirement results in significant processin 
and above the TCP layer in order to package large buffers for transmission across the network. 

Accordingly, it is desirable to improve the performance of data processing systems, by simplifying the 
higher layer processing which must be performed by the host system in order to transmit large quantitie: 
data across data networks. 

SUMMARY OF THE INVENTION 

According to the present invention, a significant portion of the higher layer transmit processing is 
offloaded onto a smart adapter. The present invention accomplishes this offloading without interfering v 
other processing in the system, without breaking other protocols, and without harming the performance 
the overall system. 

The present invention provides a method for sending data from a data source executing a network proto< 
such as the TCP/IP protocol stack, which includes a process for generating packet control data, such as 
TCP/IP headers for packets according to the network protocol. The method includes sending such data c 
network through a smart network interface. According to the process, the network protocol defines a lar 
datagram from the data source (buffer), including generating a packet control data template and supplyii 
a data payload. The datagram is supplied to the network interface. At the network interface, a plurality c 
packets of data are generated from the datagram. The plurality of packets include respective packet cont 
fields, such as TCP/IP headers, based on the packet control data template, and include respective segme: 
of the data payload. According to the present invention, the network interface supports packets having a 
pre-specified length, and the data payload is greater than the pre-specified length, such as two to forty 
times larger or more. 

Thus, the higher layer processing specifies a very large datagram, which is automatically segmented at t 
network interface layer, instead of at the TCP layer. Significant host processing is thus offloaded to a sn 
network interface. For the Ethernet example in which the maximum packet size on the medium is 1514 
bytes, the protocol according to the present invention is allowed to pass much bigger datagrams, up to 6 
bytes or more, knowing that the smart adapter will take care of segmenting them into proper sized Ether 
packets and transmitting them. Except for the fact that the datagrams are very large, substantially the sai 
interface and data structure can be used. 

According to other aspects of the invention, the network protocol comprises TCP/IP. The TCP/IP heade 
template has an IP total length field set to indicate the length of the data payload. The step of generating 
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the network interface a plurality of packets includes setting the IP total length fields in the plurality of 
packets based on the size or sizes of the respective segments of the data payload included in the plurality 
packets. Also, in the TCP/IP header template, an IP identification field is set to an initial value for the 
datagram. In generating the packets at the network interface layer, IP identification values are set based 
the initial value, such as by using the initial value for the first packet, and incrementing it thereafter unti 
all packets for the datagram have been transmitted. In addition, the TCP/IP header template includes an 
initial TCP sequence number for the datagram. In generating the plurality of packets, TCP sequence 
numbers are provided in each packet based on the initial TCP sequence number and the size or sizes of 1 
respective segments of the data payload. According to another aspect of the invention, the TCP/IP head* 
for TCP/DP protocols includes an IP header checksum field, and a TCP checksum field. In generating tto 
plurality of packets based on the datagram, the network interface computes the IP header checksums an< 
TCP checksums for each of the plurality of packets. 

Other TCP/IP functions are either disabled or supported for the large datagrams, without requiring 
modification of the underlying protocol functions. 

The present invention can also be characterized as a method for sending data from a data source executi 
a TCP/IP network protocol. The method according to this aspect includes establishing a connection wit! 
destination for a session according to the TCP/IP network protocol. Next, a TCP window size is 
determined from the destination which indicates an amount of data the destination is ready to receive. T 
datagram is defined in the data source by generating a TCP/IP header template and supplying a data 
payload having a size less than or equal to the window size. The datagram is supplied, along with a 
segment size parameter and a request to segment the datagram to the network interface. In the MAC drr 
in the network interface, a plurality of packets are generated in response to the segment size parameter a 
to the request to segment. The plurality of packets is composed from the datagram by executing process 
in the network interface to provide respective TCP/IP headers based on the TCP/IP header template, to 
provide respective segments of the data payload having lengths equal to or less than the segment size 
parameter, and to compute IP header checksums and TCP checksums for the plurality packets. The paci 
are then sent to the destination. Finally, an acknowledgment is received from the destination that the 
plurality of packets was successfully sent according to the network protocol. 

If a TCP packet with a non-zero data payload is received before a last packet in the plurality of packets i 
sent, then there is a possibility that the windowing and sequencing of the TCP protocol will fall out of 
synchronism. This can be ignored, or a variety of optional techniques can be applied to handle it or redu 
its impact. Thus, according to one alternative, all unsent packets in the plurality of packets for the datagi 
are abandoned by the network interface if a TCP packet with a non-zero payload is received before the 1 
packet is sent. It is responsibility of the higher layer to resend the datagram in this case. According to 
another alternative, the step of generating the plurality of packets includes the processes before sending 
each packet of determining whether a more recent datagram for the same session has been supplied to tt 
network interface. If no more recent datagram has been supplied, then the TCP header acknowledgment 
number and window field are set to the values in the TCP/IP header template. If a more recent datagram 
has been supplied, then the TCP header acknowledgment number and window field are set to the values 
the TCP/IP header template of the more recent datagram. According to another alternative, the MAC in 
network interface may hold onto the received packets for this session until the last packet has been sent. 

According to yet another aspect of the invention, the process includes sending a plurality of datagrams t 
the network interface for the same session. Sequence numbers are assigned to the plurality of datagrams 
The step of generating the plurality of packets for current datagram includes determining whether a mor 
recent datagram has been supplied having a sequence number which precedes a sequence number in the 
current datagram. If it has, then the generating of the plurality of packets for the current datagram is 
stopped, and the generating of the plurality of packets for the more recent datagram is begun. This tends 
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maintain the order of transmission to a greater degree, in the event that an earlier transmitted datagram i 
the sequence is being retransmitted. 

Also, in the process of sending a plurality of datagrams to the network interface for the same session, th- 
step of generating the plurality of packets for a current datagram includes for a last packet in the pluralit 
of packets, determining whether data from a following datagram falls in sequence with it. If it does, thet 
data from the current datagram may be concatenated with data from the following datagram to compose 
the last packet. 

A variety of other optimizations and techniques for offloading TCP/IP segmentation to a smart adapter i 
provided according to the present invention. Furthermore, the present invention is also extendable to 
offloading further TCP layer send processing to the smart adapter. 

These processes provide significant benefits. For example, servers send more data than they receive, an< 
most network benchmarks are even more heavily weighted to sending. Handling a large quantity of data 
the TCP layer allows the protocol, for example, to avoid allocating blocks of data for copies of the pack 
header, copying it, and freeing it. A variety of other processes involved in the transitions from protocol i 
driver are also avoided, including a variety of interrupts for transmit completions for the packets, for 
acknowledgments of the packets, and for other processing steps. 

According to other variations, a shared state structure can be created in which ACK and window 
parameters for the TCP/IP protocol stack are maintained. The MAC driver updates the ACK and Windo 
parameters in outgoing packets from the shared structure periodically. Also, in other embodiments the 
windowing and retransmission algorithms are handled at higher layers without requiring the network 
interface to pick these up. The protocol would simply have to limit itself to payload data up to the end o 
the advertised window. Other subsets and variations are also possible. For example, the MAC driver coi 
manage the transmit window, watching incoming receive frames for an opening in the window and only 
transmitting datagrams within the current window. 

Other aspects and advantages of the present invention can be seen upon review of the figures, the detaih 
description, and the claims which follow. 

BRIEF DESCRIPTION OF THE FIGURES 

FIG. 1 is a simplified block diagram of a data processing system with offloading according to the preser 
invention. 

FIG. 2 is a simplified block diagram of a smart network interface card implementing the TCP segmental 
of the present invention. 

FIG. 3 is a network protocol layer diagram which provides a simplified illustration of the present 
invention. 

FIG. 4 is a simplified diagram of a TCP/IP header template generated according to the present invention 

FIG. 5 provides a flow chart of the datagram handling processes executed by the network interface 
according to the present invention. 

FIG. 6 illustrates optional inter-packet processes to be executed by the network interface. 

FIG. 7 illustrates another optional inter-packet process to be executed by the network interface driver. 
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DETAILED DESCRIPTION 

A detailed description of the present invention is provided with respect to FIGS. 1-7, in which FIGS. 1 £ 
2 illustrate the hardware system environment. 

FIG. 1 shows a data processing system 10 which includes a host central processing unit 11, host memor 
12, host input/output devices 13, such as keyboards, displays, printers, a pointing device and the like. Tl 
system also includes a program memory 14 (usually part of the host memory block) and a network 
interface card 15. All these elements are interconnected by a host system bus 16. The network interface 
card 15 provides for connection to a network medium as indicated at line 17. 

FIG. 1 is a simplified diagram of a computer, such as a personal computer or workstation. The actual 
architecture of such systems is quite varied. This system for one example corresponds to a personal 
computer based on the Intel microprocessor running a Microsoft Windows operating system. Other 
combinations of processor and operating system are also suitable. 

According to the present invention, the program memory includes a TCP/IP protocol stack with a 
segmentation mode according to the present invention. A MAC driver is also included in the program 
memory which supports the segmentation mode. Other programs are also stored in program memory to 
suit the needs of the particular system. The network interface card 15 includes resources to manage TCP 
segmentation according to the present invention. 

FIG. 2 provides a simplified block diagram of the network interface card 15 of the present invention. Th 
network interface card 15 includes a bus interface 20 coupled to the host bus 16. A memory composed c 
random access memory RAM 21 is included on the card 15. Also, a medium access control unit 22 is 
coupled to the card which is coupled to the network interface 17. The path from the host bus interface 2i 
the RAM 21 includes appropriate buffering 25 and a DMA engine 26 in order to offload processing fror 
the host system for transferring data packets into the RAM 21. Also, the data path from the RAM 21 to i 
MAC unit 22 includes appropriate data path and buffering logic 26 to support efficient transmission and 
reception of packets. A DMA engine 28 is also included on this path to provide for efficient transferring 
data between the network medium 17 into the RAM 21. Also included on the card 15 is a central 
processing unit 30 having a program memory 3 1 . The CPU 30 is coupled to the host bus 16 and to the 
RAM 21 on line 32. Also, the CPU 30 generates control signals represented by the arrow 33 for control] 
other elements of the network interface card 15. Also according to this embodiment, TCP/IP checksum 
logic 34 is coupled to the data path and buffering logic 27 in the path from the RAM 21 to the network 
medium 17. The program memory for the CPU 30 includes the transmit, receive, TCP/IP segmentation 
control and other processes which manage the operation of the smart adapter card. 

The block diagram illustrated in FIG. 2 provide a simplified overview of the functional units in a netwoi 
interface according to the present invention. A variety of other architectures could be implemented to 
achieve similar functions. For example, DMA engines 26, 28 are not strictly required here. State machir 
handshaking with each other, or other data processing resources could move data from one block to the 
next. 

In one embodiment, all of these elements are implemented on a single integrated circuit. In another 
embodiment, all elements except for the RAM 21 are implemented on a single integrated circuit. Other 
embodiments include discreet components for all of the major functional blocks of the network interface 
card. 

FIG. 3 is a simplified diagram of the network protocol layers implemented according to the present 
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invention. The protocol layers include a data source 50 which corresponds to the higher layers of the 
network protocol. The data source is coupled by path 5 1 to the TCP/IP stack 52. The TCP/IP stack 52 is 
coupled by a path 53 to the MAC driver 54. The MAC driver is coupled by path 55 to the smart networi 
interface card 56. The smart network interface card 56 is coupled by path 57 to the network medium. 

According to the present invention, the data source 50 sends a big buffer across path 51 along with a 
command on line 60 to the TCP/IP stack 52. The TCP/IP stack 52 generates appropriate indications on 1 
61 to the data source 50 to manage delivery of the big buffer to its destination. 

The TCP/IP stack 52 determines that segmentation offload is suitable for the buffer based on a variety o 
network state parameters. If it is suitable, then a template header, such as shown in FIG. 4, and out-of-b; 
data are sent on line 62 to the MAC driver 54. The out-of-band data includes a segmentation command ; 
a maximum segment size MSS. Gather descriptors GDs for the datagram to be sent are also supplied foi 
the buffer. The MAC driver 54 registers the capability to do the segmentation offload processing with tl 
TCP/IP stack 52, and supplies appropriate indications to the TCP/IP stack 52 to manage delivery of the 
data on line 63. The MAC driver 54 sends the transmit command with segmentation along with the 
template header, the gather descriptors for the buffer, and the MSS parameter as indicated at line 64 to t 
smart network interface card hardware 56. The smart network interface card 56 also sends appropriate 
indications on line 65 back to the MAC driver 54. The smart network interface hardware 56 processes tl 
datagram by segmentation according to the parameters supplied by the higher layers, and sends the 
datagram segmented into packets on the network medium 57. 

One preferred embodiment of the present invention is to support the Windows 32 (Windows NT, Windc 
95) operating systems provided by Microsoft Corporation. According to the Windows 32 environment, i 
so-called NDIS specification provides the functionality of the MAC driver layer of the protocol stack. T 
MAC driver is modified to implement the new TCP segmentation functionality according to the present 
invention in this example. When supported by the driver, an aware TCP/IP stack can offload certain 
processing to the adapter. 

The TCP/IP protocol passes "large datagrams" to the NDIS drivers MiniPortSend routine. These 
datagrams are properly formatted, except for the IP and TCP checksums. Normal media, IP, and TCP 
headers are present, along with a larger than usual payload. Along with the datagram, a session MSS wi 
be passed, telling the driver what size pieces to cut the payload into. The driver will then cut the datagra 
into packets, using the "template" headers from the datagram along with certain simple rules to produce 
actual packets to be sent on the media. 

For this example, the protocol can pass down only payload which can be transmitted immediately, ie. is 
within the advertised window of the other side. 

A "large datagram" send may not be completely sent by the MAC driver. On completion, the TCP/IP 
protocol might look at some NextSEQ field to determine how much payload the driver actually sent, an< 
perhaps where to pick up again with the next send attempt. 

The term "datagram" is used herein to refer to the buffer, such as a large NDIS- PACKET, passed dowi 
from the protocol to the MAC driver for segmentation. 

The term "packet" is used generally to refer to the media-sized packets that result from segmenting the 
datagram. 

The headers of the datagram are the "template", since they are copied to the media packets during 
segmentation with a few simple changes. 
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The data beyond the TCP/IP header in the datagram is referred to as the "payload". 

This description is generally written from the point of view of the MAC driver. As such "incoming" reft 
to datagrams being passed down from the protocol, and "outgoing" refers to packets being transmitted o 
the wire after segmentation. 

Basically we have substituted a single "large packet" send for a number of smaller sends. The goal is to 
reduce host CPU utilization and improve performance and scalability. Each MiniPortSend call to send a 
packet must handle transitions from TCP thru IP, various intermediate drivers and the NDIS miniport 
wrapper to the MAC driver, as well as handle similar transitions on send completion. This overhead can 
quite significant at high wire speeds. Also, though computing the header for each new packet is likely qi 
simple (ack+=bytes; id++; etc), the header must be copied to a new buffer for each send. An NDIS— 
PACKET structure must be obtained from a free queue, filled in, queued elsewhere, etc. And of course 
there is a significant physicalization penalty for each packet. Also the number of interrupts on the host 
CPU is reduced to one per "large packet" rather than one per packet or one per some number of packets 
(algorithmic). Offloading TCP segmentation to the adapter will help reduce all of this quite significantly 

This description is based on Internet Protocol, version 4, IPv4 processing, though other versions are alsc 
suitable. For IPv4, the processing is managed as follows: 

The IP Total Length field is 16 bits and as such limits the size of the incoming datagram IP+TCP+Paylc 
to 64k. This specification allows larger payloads for example by setting the IP Total Length field to zerc 
(0) on incoming datagrams (in this case the length of the incoming datagram must be determined by 
examining the GD). 

The IP "don't fragment" bit is legal. The IP "more fragments" bit is not. If IP fragmentation is required, : 
must be done by the protocol. As such the IP fragment offset field must be zero also. 

The IP Header Checksum field can be left undefined. 

Various TCP flags are illegal on incoming datagrams to be segmented. The RST, SYN and FIN flags an 
all disallowed. 

The TCP Checksum field can be left undefined. 

TCP and IP options are allowed but will be sent on each packet which may not be appropriate. In 
alternatives, more management of the options field could be executed in the NIC, to handle each packet 
which the template applies individually, for example. 

The MAC driver takes the incoming datagram, consisting of a template header and a payload, and carve 
up into packets. Packets are generated by cutting the payload into chunks based on the MSS passed dow 
All packets but the last will have a payload exactly MSS bytes in size. The last may be smaller. 

The header of outgoing packets is derived from the template header on the incoming datagram as follow 

The sizes of the media, IP, and TCP headers are all identical to those in the template. 

Unless otherwise specified, fields are simply copied from the template to the outgoing packet without 
change. 



file://C:\Documents%20and%20Sett 2/9/2005 



AU1 126699 



Page 9 of 24 



The media header is used exactly. 

The IPv4 header is copied exactly, except: 

the IP Total Length field in the outgoing packets is computed correctly for each packet. 

the IP Identification field (ID) is advanced for each packet, with the first packet's ID copied from the 

template, the second's set to that plus one, etc. The protocol can either determine exactly how many IDs 

will be consumed by the call, or simply advance the ID field by a sufficient amount (64k/536 is 122). Si 

no retransmits will be done by the driver (or if they are, the same IDs will be used), the IDs that will be 

used by the driver are completely predictable. 

the IP Header Checksum is computed for each packet. 

The TCP header is copied exactly, except: 

the Sequence Number (SEQ) is advanced for each packet. So the SEQ for the first packet is copied fron: 

the template, the SEQ for the second is advanced by MSS bytes, or the actual length. 

the PSH bit is set to zero outgoing, unless the PSH bit was set in the template, in which case it is set on i 

last packet in the datagram. 

the TCP checksum is computed for each packet. 

the URG bit is set to zero outgoing, unless the urgent pointer falls within this packet in which case it is s 
to one, and the URGENT POINTER is set also (it is otherwise zero). 

The template establishes ACK and Window values for the outgoing segmented packets. In most cases tt 
should be sufficient. Most flows are unidirectional, and segmentation will likely only be used to send la] 
blocks of data. So usually there will be no receive traffic (other than ACKs) while we are sending out a 
large datagram. 

If receive traffic on this session does occur (a receive packet arrives for this session with a non-empty T 
payload) the ACK and Window fields could get out of date. Alternatives for handling this event include 
the following: 

1) Ignore the issue. This would also happen with an adapter with a large transmit FIFO/queue using non 
packets. 

2) Receiving a data packet on a session in Segmentation Mode will cause us to abandon any pending sei 
for that session or that datagram. The completions will indicate how far we got, and the protocol can iss 
new sends with updated ACK/Window fields out of their receive packet handler. 

3) The process can assume that more recently submitted sends have more accurate information. In this 
case, the smart network interface can carry the ACK/Window fields out of any more recent packets 
forward to packets being transmitted now from a current datagram. ACK/Window fields would be 
automatically updated as new datagrams were submitted, and ACK packets could be sent to do this with 
sending any data. Note that the ACKs themselves would not be deleted, just their ACK/Window 
information carried forward. 

4) The protocol could maintain ACK and Window values for this session in an agreed upon location anc 
the adapter could update the copies in the template periodically. 

5) The MAC driver could hold onto receive packets for this session until the entire large datagram had 
been transmitted. 

To abandon sends on a session, the driver completes the first send datagram by calling 
NdisMSendComplete with an error, NDIS-- UNEXPECTEDRX. Any new sends submitted on this sessi 
up to the point where NdisMSendComplete returns to the driver will also be abandoned. When 
NdisMSendComplete returns to the driver from that first send, all of the pending packets/datagrams for 
that session are moved in an atomic operation to a special queue where they will be completed with the 
same error. Any new sends submitted from then on will be sent normally. The TCP protocol submits the 
from its receive packet handler (it knows this is coming because of the special error code). This avoids z 
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critical section problem. 

Protocols might have multiple segmentation datagrams outstanding on a single session at once. When a 
session has one or more outstanding datagrams queued up against it, it is said to be in "Segmentation 
mode". In this mode if another datagram (or even a regular packet) for the same session is submitted, it 
will also be queued for sending on this session. 

It is expected that such datagrams often will be sequential, ie. that the SEQ of a second packet will be 
equal to the SEQ of the first plus the size of the payload in the first datagram. 

Datagrams queued up for a session need not have their payload a multiple of the MSS in size. As such il 
two sequential datagrams are queued up for a session, an outgoing packet might result from bytes at the 
end of the first datagram and bytes at the start of the second. 

According to one embodiment, the driver will attempt to send pending datagrams for a given session in 
SEQ order. Thus if an incoming series of ACKs causes the protocol to want to resend some old data, the 
more recent datagram with that old SEQ will get priority over other payload data with later SEQ's 
including the current datagram. The driver should be prepared to switch over from the current datagram 
partially transmitted to another more recent datagram with an earlier SEQ if such is submitted. This nee« 
not be done instantaneously, but should be done reasonably quickly. The idea here is that if the protocol 
wants to retransmit some older payload, that retransmit is given some priority. 

In another feature, the driver can take advantage of later templates. If a second datagram is queued up 
against a session with more recent ACK and Window information, the driver could take advantage of th 
even while still transmitting the first datagram. 

In order to support the Simple TCP Segmentation offload, a bit in some agreed upon word indicating th< 
capability can be set. 

When the TCP/IP stack sends a datagram on which it wants TCP Segmentation to be done by the driver 
sets the following bit in Send Flags, or its equivalent in OOB- DATA or some new location in NDIS-- 
PACKET: 

fNDIS- PACKET- TCPSEG 

Also in a location in the OOB- DATA (or a new location in NDIS-- PACKET) the value: 
UINTMSS; 

passes the MSS for this session down to the driver to be used in cutting up the payload into packets. Thi 
value may also be sent as part of a structure by passing a pointer instead. 

MiniportSendPackets is equivalent to MiniportSend. 

In the NdisMSendComplete block, when the driver completes a datagram on which it has done TCP 
Segmentation, it sets the following bit (or its equivalent) in Send Flags: 

fNDIS- PACKET- TCPSEG 

Also in a location in the OOB- DATA (or elsewhere in NDIS-- PACKET) is passed: 
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UINT NextSEQ; 

where NextSEQ is the sequence number following the last byte sent by the MAC. Again this might be p 
of another structure by passing a pointer to that structure instead. If the entire datagram was sent then th 
is the byte after the entire payload in the datagram, ie. template SEQ+len(payload). If for some reason tl 
entire datagram was not sent, this is the byte at which the protocol might want to pick up sending again. 
Since multiple datagrams can be queued up, NextSEQ could be well after the last byte of payload in this 
datagram and still indicate success. 

The protocol need not look at NextSEQ unless an error is indicated. If Status is NDIS-- STATUS- 
SUCCESS, the entire datagram was sent. However, if one of the following new errors (or their equivale 
is indicated, the protocol will have to look at NextSEQ: 

NDIS-- STATUS- UNEXPECTEDRX-a packet was received on this session with a non-empty TCP 
payload. As a result we are abandoning any sends or other option queued up for this session. 

NDIS- STATUS- INCOMPLETE-some of the datagram was transmitted but not all. The protocol she 
pick up where the driver left off. 

In general the driver should behave as it would have if packets were sent individually. So the statistics 
should be updated based on the outgoing segmented packets, not the incoming datagrams. 

FIG. 4 illustrates the structure of the datagram generally 100 which includes the large payload with 
standard control structures in a template format. The control structures include the basic MAC layer hea 
101, an Ethernet header in this example, followed by an IP header 102, followed by a TCP header 103. 
After the control structures, an extra long payload 104 is coupled to the datagram. Also with the datagra 
100 according to a preferred embodiment is an out-of-band segmentation structure 105. The out-of-banc 
OOB segmentation structure includes the MSS parameter, and the request to segment. Other state variat 
may also be passed through this out-of-band code 105 to facilitate communication among the protocol 
layers. 

The IP header 102 consists of basically the standard IP header 1 10. The header 1 10 in this example is ar 
version 4 header which consists of five 32 bit words (dwords). The first four bits of the first dword prov 
the version field indicating the format of the header. The IHL field specifies Internet header length whic 
is equal to the length of the Internet header in 32 bit words. Thus, this points to the beginning of the TC) 
header 103. The next field provides the type of service indication. The type of service indication relates 
the quality of service desired according to the Internet Protocol. Following the type of service field is th< 
total length field. The total length field is the length of the datagram which in this version is 16 bits. Thi 
allows for a datagram to be up to 65,535 octets. In prior art systems, such long datagrams are impractica 
for most hosts and networks. However, according to the present invention, the total length field provide: 
the total length of the datagram to be segmented at the lower layers. In alternatives, this field can be set 
zero, and the length of the datagram supplied out-of-band. 

The first field in the second dword of the Internet header 1 10 is the identification field. This provides an 
identification value assigned by the sender to aid in assembling the fragments of the datagram at the 
destination. The template header according to the present invention provides an identification field whic 
provides an identification to be used for example in the first packet of the plurality of packets to be 
composed. The identification number is incremented for each subsequent packet in the plurality of pack 
composed from a single datagram. 

The next field provides various control flags. Bit zero is reserved. Bit one DF indicates whether the 
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datagram may be fragmented or not. This don't fragment bit may be used in the template. The more 
fragments MF bit (bit two) is not legal as mentioned above. 

The next field specifies the fragment offset. This field is set to all zeros in the template. 

The first field in the third dword of the header is a time to live parameter. This field indicates the 
maximum time the datagram is allowed to remain in the Internet system. 

The next flag specifies the protocol. This field indicates the next level protocol used in the data portion < 
the Internet datagram. In this embodiment, the next level protocol is TCP. 

The next field in the IP header template is the header checksum. According to the present invention, the 
header template leaves the header checksum undefined, such as by leaving it all zeros or otherwise. The 
checksum is computed in the smart network interface for each packet carrying a segment of the datagrai 
as it is transmitted. 

The next fields in the Internet Protocol header template are the source address followed by the destinatic 
address. These addresses are supplied in the template header and are copied directly into the headers of 
packets carrying segments of the datagram. The last two fields include the options field and a padding 
field. IP options are not allowed according to one embodiment of the present invention. With more 
sophisticated algorithms, options can be implemented which are indicated by this header field. The Intel 
header padding is used to ensure that the Internet header ends on a 32 bit boundary. 

Thus, the Internet header template 1 10 looks like the standard Internet header. However, the fields havh 
an astricks in the figure are used as described above according to this example of the present invention. 

The TCP header template 1 12 is also shown in FIG. 4. The TCP header template 1 12 specifies the sourc 
port and the destination port in a first dword of the header according to the TCP specification. After the 
destination port, a sequence number is provided. The sequence number is a 32 bit sequence number 
corresponding to the number of the first data octet in this segment. The sequence number in the template 
used in the header for the packet carrying the first segment of the datagram. Sequence numbers are upda 
automatically by the smart interface card for each subsequent packet carrying a segment of the datagran 

The next field in the TCP header template is the acknowledgment number. This is a 32 bit control field 1 
contains the value of the next sequence number a sender of the segment is expecting to receive if the AC 
bit is set. Once a connection is established, this parameter is always sent. Thus, the value is included in 1 
TCP header template and copied directly for each packet of the plurality of packets sent for the datagran 
according to this embodiment of the present invention. In other embodiments, the acknowledgment 
number is automatically updated using processing in the smart interface during the processing of the 
datagrams. 

The next field in the TCP header template is the data offset. This is a 4 bit number which indicates the 
number of 32 bit words in the TCP header. This indicates where the data pay load 104 begins. After the 
data offset, a 6 bit reserved field is placed in the header. After that, 6 control bits are provided. These 
control bits are handled as discussed above for the TCP header template. After the control bits, the wind 
parameter is provided. This is the number of data octets beginning with the one indicated in the 
acknowledgment field (acknowledgment number in the template) which the sender of this segment is 
willing to accept. The window value is again copied for each packet to be sent which carries segments o 
the datagram. In some embodiments, the window parameter can be updated by the smart interface card i 
mentioned above. 
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Following the window field is the checksum field. According to the template, the checksum is left 
undefined. The checksum is computed for the TCP segment for each packet to be transmitted carrying a 
segment of the datagram. 

After the checksum field, the urgent pointer field is provided. This field communicates the current value 
the urgent pointer as a positive offset from the sequence number in this segment. This field is only 
interpreted when the URG control bit is set, which is not allowed in one embodiment of the segmentatio 
process of the present invention. Thus, the TCP urgent pointer must be set to zero in the template for thi 
example. Alternatively, the URG bit and URG pointer may be allowed, and set when we transmit the 
packet the URGENT pointer indicates. That is, the adapter sets the URG pointer in the packet which 
carries the byte which the URG pointer in the template identifies. 

Following the urgent pointer is the options field for TCP. The options field is allowed, and can be set to 
any of the variable option values allowed according to the TCP protocol. Thus, the option field can be a 
single octet indicating the option kind, or an octet indicating option kind, an octet indicating option leng 
and the actual option data octets. After the options field, the padding field is defined to ensure ending or 
32 bit boundary in the heading. 

After the padding, the actual data pay load 104 is found. As mentioned above, an astricks in the fields of 
the TCP header template 1 12 in FIG. 4 indicate which fields are involved in the template processing for 
this example. 

The out-of-band segmentation code 105 illustrated in FIG. 4 can be provided in a variety of manners. F< 
example, this segmentation code may be provided by supplying it as an element of a reserved field in th 
template headers. The reserved fields are read by the smart interface card, and the control codes are 
removed from the headers of the packets carrying segments of the payload. An alternative embodiment, 
out-of-band communication can be provided by providing a shared state variable for use by the network 
interface card and the higher layer protocols. By reading and writing from the shared state variable, all t 
information concerning the segmentation process can be provided to the various layers of processing. Tl 
out-of-band data can also be provided in the NDIS environment by using reserved fields in the NDIS 
packet structure. 

This example is based on version 4 of the Internet protocol. Other versions are also suitable for 
implementation of the present invention with modifications of the templates as appropriate. Furthermon 
the present invention may be applied to other network protocol stacks as suits a particular implementatk 

FIGS. 5-7 illustrate the processing executed in the smart network interface card according to the present 
invention. These processes are executed by the CPU on the network interface card 15 under control of 
computer software stored in the program memory of the network interface. Alternative systems may 
implement these processes in a dedicated state machine or other dedicated logic on a network interface 
card. Other techniques for implementing the offloading this processing from the host processor may als< 
be used. 

FIG. 5 shows the basic processing which results in offloading of the segmentation of a large datagram ii 
a plurality of packets based on the TCP/IP header template and the large datagram of FIG. 4. The proce* 
begins when the network interface driver receives a send request from the driver (step 200). The networ 
interface determines whether the segmentation command is included with the request (step 201). If not, 
packet is pulled from the host buffers using the gather descriptors provided by the driver (step 202). The 
packet is then provided to a send process for transmission on the network according to the MAC layer 
processes (step 203). The process ends upon successful transmission of the packet (step 204). 
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If at step 201, the segmentation command had been received with the send request, the algorithm brand 
to step 205. At step 205, the smart interface reads the MSS parameter from the out-of-band data provide 
with the datagram. The driver then proceeds to pull MSS sized segments using the gather descriptors foi 
the datagram (step 206). The adapter might A) download the whole large datagram and cut it up on the 
adapter or B) only download the header (and perhaps some of the payload) and download additional 
payload as needed. As the segments are pulled, a header is produced from the template header and 
checksums are computed (step 207). The process of computing the header for each packet in the pluralit 
of packets being generated for each datagram includes incrementing the identification field for each pac 
after use of the identification field in the template for the first packet, computing the checksums, and 
setting the sequence number for each subsequent packet as appropriate, typically equal to the sequence 
number of the previous packet plus its length which is equal to MSS in the normal case, except for usua 
the last packet in the set. Finally the actual length of the packet is calculated and set for the packet to be 
transmitted. The other processing for the special control parameters and the like is provided as discussec 
above. 

The packet send process is then executed for the current segment of the datagram (step 208). After the 
packet send process, the algorithm determines whether the datagram is finished (step 209). If it is finish 
then the process ends at step 204. The packet send process may be initiated for a given packet, while ste 
209 is executed for a following packet in parallel. If the datagram is not finished at step 209, then optior 
inter-packet processes (block 210) are executed and the algorithm returns to step 206 to pull the next M! 
sized segment (or less at the end of the datagram). The optional inter-packet processes 210 include for 
example the processes of FIGS. 6 and 7. In a simplified embodiment, there are no inter-packet processes 
and the algorithm is repeated until the datagram is finished. 

FIG. 6 illustrates example inter-packet processes which begin at step 300, when the inter-packet process 
called by the network interface. First, the inter-packet process involves determining whether a more rec< 
datagram has been supplied from the higher layers (step 301). If yes, then it is also determined whether ; 
more recent window and acknowledgment fields are being provided by the more recent datagram (step 
302). If they are more recent, then the template for the current datagram is updated (step 303). If not, or 
after updating the template, the process then proceeds to determine whether the sequence parameters in 
template are out of order between the current datagram and the more recent datagram (step 304). If the 
sequence parameters are out of order, then the current datagram is stopped, and the process for the more 
recent datagram is initiated (step 305). Thus for example, if the more recent datagram has an earlier 
sequence number than the sequence number of the current datagram, then it indicates that data is being 
retransmitted from earlier in the sequence. In this case, it is efficient in some circumstances to stop 
transmitting of the current datagram, and send the datagram carrying the earlier sequence number to 
improve the order of reception at the destination. 

If at step 304, the sequence processing is not out of order, or at step 301, there is no more recent datagra 
then the process branches to step 206 of FIG. 5 to return to processing of the current datagram. 

FIG. 7 illustrates another inter-packet process which may be executed at point 210 in FIG. 5. This inter- 
packet process begins at step 400 upon calling of the inter-packet process. The algorithm first determine 
whether a TCP packet with a non-zero payload has been received for this session (step 401). If such a 
packet is received, then the datagram is abandoned and further packets are stopped (step 402). After 
stopping the sending of the current datagram, a send error is reported to the TCP/IP stack (step 403) whi 
has responsibility for retrying the datagram. After reporting the send error, the process ends (step 404) li 
at step 204 of FIG. 5. Also, if no such packet is received at step 401, then the process returns (step 405) 
normal processing of the current datagram. 

The inter-packet processes of FIGS. 6 and 7 could all be implemented, or could be implemented one at i 
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time in a particular embodiment of the present invention. Also, as other functions of the TCP protocol f< 
the transmit process are offloaded to the smart network interface adapter, additional inter-packet process 
could be executed. 

For example, the adapter processing can be limited by providing a packet control field template which 
matches a TCP/IP header template, and having TCP, URG, RST, SYN and FIN flags set to no action 
states, and the urgent pointer field set to zero. 

In an alternative, the URG flag and URG pointer identifying a byte in the datagram may be set in the 
template, and the network interface sets the URG flag and URG pointer in a packet in the plurality of 
packets which includes said byte. 

In another alternative, the FIN flag is included in the template, and the network interface, if the FIN flag 
set in the TCP/IP header template, sets the FIN flag in a last packet in the plurality of packets. In anothe 
alternative, the PSH flag is included in the template, and the network interface, if the PSH flag is set in t 
template, sets the PSH flag in a last packet (or other packet as determined by the context of the send 
process) in the plurality of packets. 

Thus, the present invention offloads common processing functions to the adapter, while leaving as mucl 
complexity and flexibility on the host as possible. The results are improved performance, reduced host 
CPU utilization, and improved scalability of the process. Further, the function is implemented without 
adding new functions or interfaces to the existing network driver specifications for standard systems, su 
as the NDIS. Further, the preferred system remains compatible with intermediate drivers to the extent 
possible. 

The foregoing description of a preferred embodiment of the invention has been presented for purposes c 
illustration and description. It is not intended to be exhaustive or to limit the invention to the precise fori 
disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in this 
It is intended that the scope of the invention be defined by the following claims and their equivalents. 

Data supplied from the esp@cenet database - Worldwide 
Claims of corresponding document: US5937169 



What is claimed is: 

1. A method for sending data on a network from a data source executing a network protocol which 
includes a process for generating packet control data for packets according to the network protocol, 
through a network interface including medium access control layer processes, comprising: 
establishing a connection with a destination for a session according to the network protocol; 
determining a window size from the destination according to the network protocol, which indicates an 
amount of data the destination is ready to receive; 

defining a datagram in the data source, including generating a packet control data template and supplyin 
data payload having a size less than or equal to the window size; 
supplying the datagram to the network interface; 

generating in the network interface, a plurality of packets from the datagram, the plurality of packets 
including respective packet control data based on the packet control data template, and including 
respective segments of the data payload; 
sending the plurality of packets to the destination; and 
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receiving acknowledgment from the destination of receipt of the plurality of packets according to the 
network protocol. 

2. The method of claim 1, wherein the acknowledgment carries an indication of an updated window size 
for the destination. 

3. The method of claim 2, including if a packet with data is received for the session before a last packet 
the plurality of packets is sent, then abandoning the unsent packets in the plurality of packets, and 
resending the datagram. 

4. The method of claim 1, including holding acknowledgment and window values for a given datagram 
session in a location accessible by the network interface, and reading in the network interface the values 
stored in said location during the sending of the plurality of packets. 

5. The method of claim 1, including holding in the network interface, recieved packets during the sendii 
of the plurality of packets, until the plurality of packets has been sent. 

6. The method of claim 1, wherein the step of supplying includes providing a segment size parameter, ai 
a segmentation request to the network interface. 

7. The method of claims 1, wherein the step of supplying includes providing a segment size parameter 
outside the datagram. 

8. The method of claim 1, wherein the packet control data template includes a reserved field, and the ste 
of supplying includes providing a segment size parameter to the network interface by a path outside the 
datagram and a segmentation request to the network interface by setting a bit in the reserved field. 

9. The method of claim 1, wherein the step of supplying includes providing a segment size parameter an 
segmentation request to the network interface by a path outside the datagram. 

10. The method of claim 1, wherein the packet control data template includes a packet header template. 

11. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template. 

12. The method of claim 1, wherein the network interface supports packets having a prespecified length 
and the data payload is greater than the prespecified length. 

13. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template including having an IP total length field set to indicate the 
length of the data payload, and wherein the step of generating in the network interface includes setting I 
total length fields in the plurality of packets, based on size or sizes of the respective segments of the dafc 
payload in the plurality of packets. 

14. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template including having an IP identification field set to an initial 
value for the datagram, and wherein the step of generating in the network interface includes setting IP 
identification values in the plurality of packets based on said initial value. 

15. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template including having an initial TCP sequence number set for 1 
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datagram, and wherein the step of generating in the network interface includes setting TCP sequence 
numbers for the plurality of packets based on the initial TCP sequence number and the size or sizes of tl 
respective segments of the data pay load in the plurality of packets. 

16. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control dab 
template comprises a TCP/IP header template including having an IP header checksum field, and a TCP 
checksum field, and wherein the step of generating the plurality of packets in the network interface 
includes computing IP header checksums and TCP checksums for the plurality of packets. 

17. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template having a TCP header PSH flag, and wherein the step of 
generating the plurality of packets in the network interface includes if the TCP header PSH flag is set to 
no action state, setting the TCP header PSH flag in the packet headers to the no action state, and include 
the TCP header PSH flag is set to a push state, setting the TCP header PSH flag in a last packet in the 
plurality of packets to the push state, and for other packets in the plurality of packets to the no action sta 

18. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template including having a TCP header acknowledgment number 
and window field, and wherein the step of generating the plurality of packets in the network interface 
includes setting the TCP header acknowledgment number and window field to the values in the TCP/IP 
header template. 

19. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template including having a TCP header acknowledgment number 
and window field, and wherein the step of generating the plurality of packets in the network interface 
includes before sending each packet in the plurality of packets, if no more recent datagram has been 
supplied, then setting the TCP header acknowledgment number and window field to the values in the 
TCP/IP header template, and if a more recent datagram has been supplied, then setting the TCP header 
acknowledgment number and window field to the values in the TCP/IP header template of the more rec( 
datagram. 

20. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template including having a MF flag set to indicate no fragmentati< 
and a Fragment Offset field set to zero. 

21. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template including having an IP options field set to indicate no 
options. 

22. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template including having TCP, URG, RST, SYN and FIN flags se 
no action states, and the urgent pointer field set to zero. 

23. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template having an URG flag and a URG pointer identifying a byte 
the datagram, and including in the network interface flag and setting the URG pointer in a packet in the 
plurality of packets which includes said byte. 

24. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template having an URG flag and a URG pointer identifying a byte 
the datagram, and including in the network interface setting the URG flag and URG pointer in a packet : 
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the plurality of packets which includes said byte. 

25. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template having a FIN flag, and including in the network interface, 
the FIN flag is set in the TCP/IP header template, setting the FIN flag in a last packet in the plurality of 
packets. 

26. The method of claim 1, wherein the network protocol comprises TCP/IP, and the packet control date 
template comprises a TCP/IP header template having a PSH flag, and including in the network interface 
the PSH flag is set in the TCP/IP header template, setting the PSH flag in at least one packet in the 
plurality of packets. 

27. The method of claim 1, including sending a plurality of datagrams to the network interface for the s* 
session, and wherein the step of generating the plurality of packets for a current datagram includes for a 
last packet in the plurality of packets, determining whether data from a following datagram falls in 
sequence, and if it does, then concatenating data from the current datagram with data from the following 
datagram in the last packet. 

28. The method of claim 1 , including sending a plurality of datagrams to the network interface for the s* 
session, and wherein the step of generating the plurality of packets for a current datagram includes 
determining whether a more recent datagram has been supplied, and if it has, then updating the template 
for the current datagram based upon the more recent datagram. 

29. The method of claim 1, including sending a plurality of datagrams to the network interface for the sz 
session, and assigning sequence numbers to the plurality of datagrams, and wherein the step of generatii 
the plurality of packets for a current datagram includes determining whether a more recent datagram has 
been supplied having a sequence number which precedes a sequence number in the current datagram, ar 
if it has, then stopping the generating of the plurality of packets for the current datagram, and beginning 
generating of the plurality of packets for the more recent datagram. 

30. A method for sending data on a network from a data source executing a TCP/IP network protocol 
which includes a process for generating TCP/IP headers for packets according to the network protocol, 
through a network interface, comprising: 

establishing a connection with a destination for a session according to the TCP/IP network protocol; 
determining a TCP window size from the destination, which indicates an amount of data the destination 
ready to receive; 

defining a datagram in the data source, including generating a TCP/IP header template and supplying a 
data payload having a size less than or equal to the window size; 

supplying the datagram, a segment size parameter, and a request to segment the datagram to the networl 
interface; 

generating in the network interface, in response to the segment size parameter and to the request to 
segment, a plurality of packets from the datagram, including executing processes in the network interfac 
to provide respective TCP/IP headers based on the TCP/IP header template, to provide respective segmc 
of the data payload having lengths equal to or less than the segment size parameter, and to compute IP 
header checksums and TCP checksums for the plurality of packets; 
sending the plurality of packets to the destination; and 

receiving acknowledgment from the destination of receipt of the plurality of packets according to the 
network protocol. 

31. The method of claim 30, including if a TCP packet with a non-zero data payload is received before \ 
last packet in the plurality of packets is sent, then abandoning the unsent packets in the plurality of pack 
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and resending the datagram. 

32. The method of claim 30, wherein the step of supplying includes providing the segment size paramet- 
outside the datagram. 

33. The method of claim 30, wherein the TCP/IP header template includes a reserved field, and the step 
supplying includes providing the segment size parameter to the network interface by a path outside the 
datagram, and the segmentation request to the network interface by setting a bit in the reserved field. 

34. The method of claim 30, wherein the acknowledgment carries an indication of a updated window sit 
for the destination. 

35. The method of claim 30, wherein the TCP/IP header template includes an IP total length field set to 
indicate the length of the data payload, and wherein the step of generating in the network interface inclu 
setting IP total length fields in the plurality of packets, based on size or sizes of the respective segments 
the data payload in the plurality of packets. 

36. The method of claim 30, wherein the TCP/IP header template includes an IP identification field set 1 
an initial value for the datagram, and wherein the step of generating in the network interface includes 
setting IP identification values in the plurality of packets based on said initial value. 

37. The method of claim 30, wherein TCP/IP header template includes an initial TCP sequence number 
for the datagram, and wherein the step of generating in the network interface includes setting TCP 
sequence numbers for the plurality of packets based on the initial TCP sequence number and the size or 
sizes of the respective segments of the data payload in the plurality of packets. 

38. The method of claim 30, wherein the TCP/IP header template includes a TCP header PSH flag, and 
wherein the step of generating the plurality of packets in the network interface includes if the TCP head 
PSH flag is set to a no action state, setting the TCP header PSH flag in the packet headers to the no actk 
state, and includes if the TCP header PSH flag is set to a push state, setting the TCP header PSH flag in 
last packet in the plurality of packets to the push state, and for other packets in the plurality of packets t< 
the no action state. 

39. The method of claim 30, wherein the TCP/IP header template includes a TCP header acknowledging 
number and window field, and wherein the step of generating the plurality of packets in the network 
interface includes setting the TCP header acknowledgment number and window field to the values in tfo 
TCP/IP header template. 

40. The method of claim 30, wherein the TCP/IP header template includes a TCP header acknowledging 
number and window field, and wherein the step of generating the plurality of packets in the network 
interface includes before sending each packet in the plurality of packets if no more recent datagram has 
been supplied, then setting the TCP header acknowledgment number and window field to the values in t 
TCP/IP header template, and if a more recent datagram has been supplied, then setting the TCP header 
acknowledgment number and window field to the values in the TCP/IP header template of the more rec< 
datagram. 

41. The method of claim 30, wherein the TCP/IP header template includes a MF flag set to indicate no 
fragmentation, and a Fragment Offset field set to zero. 

42. The method of claim 30, wherein the TCP/IP header template includes an IP options field set to 
indicate no options. 
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43. The method of claim 30, wherein the TCP/IP header template includes TCP, URG, RST, SYN and I 
flags set to no action states, and the urgent pointer field set to zero. 

44. The method of claim 30, wherein the TCP/IP header template having an URG flag and a URG point 
identifying a byte in the datagram, and including in the network interface flag and setting the URG poin 
in a packet in the plurality of packets which includes said byte. 

45. The method of claim 30, wherein the TCP/IP header template having a FIN flag, and including in th 
network interface, if the FIN flag is set in the TCP/IP header template, setting the FIN flag in a last pack 
in the plurality of packets. 

46. The method of claim 30, wherein the TCP/IP header template having a PSH flag, and including in tk 
network interface, if the PSH flag is set in the TCP/IP header template, setting the PSH flag in at least o: 
packet in the plurality of packets. 

47. The method of claim 30, including sending a plurality of datagrams to the network interface for the 
same session, and wherein the step of generating the plurality of packets for a current datagram includes 
for a last packet in the plurality of packets, determining whether data from a following datagram falls in 
sequence, and if it does, then concatenating data from the current datagram with data from the following 
datagram in the last packet. 

48. The method of claim 30, including sending a plurality of datagrams to the network interface for the 
same session, and wherein the step of generating the plurality of packets for a current datagram includes 
determining whether a more recent datagram has been supplied, and if it has, then updating the template 
for the current datagram based upon the more recent datagram. 

49. The method of claim 30, including sending a plurality of datagrams to the network interface for the 
same session, and assigning sequence numbers to the plurality of datagrams, and wherein the step of 
generating the plurality of packets for a current datagram includes determining whether a more recent 
datagram has been supplied having a sequence number which precedes a sequence number in the curren 
datagram, and if it has, then stopping the generating of the plurality of packets for the current datagram, 
and beginning the generating of the plurality of packets for the more recent datagram. 

50. A network interface device coupled to a host system including a data source, the data source executi 
a network protocol which includes a process for generating packet control data for packets according to 
network protocol and sending packet on the network, comprising: 

a host interface coupled to the host system, adapted to receive a datagram in the data source, the datagra 

including a packet control data template and a data payload; 

memory to store at least portions of the datagram to the network interface; 

a processor that generates a plurality of packets from the datagram, the plurality of packets including 
respective packet control data based on the packet control data template, and including respective segim 
of the data payload; and 

a medium access control unit coupled to the memory and to a network medium that manages transfer of 
plurality of packets to the network from the memory. 

51. The network interface device of claim 50, wherein the packet control data template includes a packe 
header template. 

52. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template. 
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53. The network interface device of claim 50, wherein the medium access control unit supports packets 
having a prespecified length, and the data payload is greater than the prespecified length. 

54. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template including having an IP total length fie 
set to indicate the length of the data payload, and wherein the process of generating the plurality of pack 
includes setting IP total length fields in the plurality of packets, based on size or sizes of the respective 
segments of the data payload in the plurality of packets. 

55. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template including having an IP identification 
field set to an initial value for the datagram, and wherein the process of generating the plurality of packe 
includes setting IP identification values in the plurality of packets based on said initial value. 

56. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template including having an initial TCP seque 
number set for the datagram, and wherein the process of generating the plurality of packets includes sett 
TCP sequence numbers for the plurality of packets based on the initial TCP sequence number and the si 
or sizes of the respective segments of the data payload in the plurality of packets. 

57. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template including having an IP header checksi 
field, and a TCP checksum field, and wherein the process of generating the plurality of packets includes 
computing IP header checksums and TCP checksums for the plurality of packets. 

58. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template including having a TCP header PSH f 
and wherein the process of generating the plurality of packets includes if the TCP header PSH flag is sei 
a no action state, setting the TCP header PSH flag in the packet headers to the no action state, and inclu< 
if the TCP header PSH flag is set to a push state, setting the TCP header PSH flag in a last packet in the 
plurality of packets to the push state, and for other packets in the plurality of packets to the no action sta 

59. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template including having a TCP header 
acknowledgment number and window field, and wherein the process of generating the plurality of pack* 
includes setting the TCP header acknowledgment number and window field to the values in the TCP/IP 
header template. 

60. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template including having a MF flag set to 
indicate no fragmentation, and a Fragment Offset field set to zero. 

61. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template including having an IP options field s< 
to indicate no options. 

62. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template including having TCP, URG, RST, S^ 
and FIN flags set to no action states, and the urgent pointer field set to zero. 
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packet control data template comprises a TCP/IP header template having an URG flag and a URG point 
identifying a byte in the datagram, and including in the network interface resource to set the URG flag a 
pointer in a packet in the plurality of packets which includes said byte. 

64. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template having a FIN flag, and including in th 
network interface, resources which if the FIN flag is set in the TCP/IP header template, set the FIN flag 
a last packet in the plurality of packets. 

65. The network interface device of claim 50, wherein the network protocol comprises TCP/IP, and the 
packet control data template comprises a TCP/IP header template having a PSH flag, and including in tt 
network interface, resources which if the PSH flag is set in the TCP/IP header template, set the PSH flaj 
at least one packet in the plurality of packets. 

66. The network interface device of claim 50, including resources in the network interface to read 
acknowledgment and window values stored in a predetermined location during the sending of the plural 
of packets. 

67. The network interface device of claim 50, including resources to hold in the network interface, 
received packets during the sending of the plurality of packets, until the plurality of packets has been sei 

68. A method for sending data on a network from a data source executing a network protocol which 
includes a process for generating packet control data for packets according to the network protocol, 
through a network interface, comprising: 

defining a datagram in the data source, including generating a packet control data template and supplyin 
data payload; 

supplying the datagram to the network interface; 

generating in the network interface at the medium access control layer, a plurality of packets from the 
datagram, the plurality of packets including respective packet control data based on the packet control d 
template, and including respective segments of the data payload. 

69. The method of claim 68, wherein the packet control data template includes a packet header template 

70. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template. 

71. The method of claim 68, wherein the network interface supports packets having a prespecified lengt 
and the data payload is greater than the prespecified length. 

72. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template including having an IP total length field set to indicate the 
length of the data payload, and wherein the step of generating in the network interface includes setting I 
total length fields in the plurality of packets, based on size or sizes of the respective segments of the dafc 
payload in the plurality of packets. 

73. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da ' 
template comprises a TCP/IP header template including having an IP identification field set to an initial 
value for the datagram, and wherein the step of generating in the network interface includes setting IP 
identification values in the plurality of packets based on said initial value. 
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74. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template including having an initial TCP sequence number set for I 
datagram, and wherein the step of generating in the network interface includes setting TCP sequence 
numbers for the plurality of packets based on the initial TCP sequence number and the size or sizes of tl 
respective segments of the data payload in the plurality of packets. 

75. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template including having an IP header checksum field, and a TCP 
checksum field, and wherein the step of generating the plurality of packets in the network interface 
includes computing IP header checksums and TCP checksums for the plurality of packets. 

76. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template including having a TCP header PSH flag, and wherein the 
step of generating the plurality of packets in the network interface includes if the TCP header PSH flag i 
set to a no action state, setting the TCP header PSH flag in the packet headers to the no action state, and 
includes if the TCP header PSH flag is set to a push state, setting the TCP header PSH flag in a last pad 
in the plurality of packets to the push state, and for other packets in the plurality of packets to the no act 
state. 

77. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template including having a TCP header acknowledgment number 
and window field, and wherein the step of generating the plurality of packets in the network interface 
includes setting the TCP header acknowledgment number and window field to the values in the TCP/IP 
header template. 

78. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template including having a MF flag set to indicate no fragmentatii 
and a Fragment Offset field set to zero. 

79. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template including having an IP options field set to indicate no 
options. 

80. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template including having TCP, URG, RST, SYN and FIN flags se 
no action states, and the urgent pointer field set to zero. 

81. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template having an URG flag and a URG pointer identifying a byte 
the datagram, and including in the network interface setting the URG flag and URG pointer in a packet : 
the plurality of packets which includes said byte. 

82. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template having a FIN flag, and including in the network interface, 
the FIN flag is set in the TCP/IP header template, setting the FIN flag in a last packet in the plurality of 
packets. 

83. The method of claim 68, wherein the network protocol comprises TCP/IP, and the packet control da 
template comprises a TCP/IP header template having a PSH flag, and including in the network interface 
the PSH flag is set in the TCP/] P header template, setting the PSH flag in at least one packet in the 
plurality of packets. 
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